Organizations, including corporations and other (typically large) entities, need scalable, efficient solutions for network architecture, which enables even remote, distributed components and/or legacy systems to communicate. Small businesses and other small organizations also have such needs, but design paradigms which may be sufficient for smaller entities often fail to work on the significantly larger scale required by large corporations.
One example of such a network architecture is Enterprise Service Buses (ESBs). As described in a white paper by Steve Craggs (“Best-of-Breed ESBs”, EAI Industry Consortium, Saint Consulting Limited, 2003), ESBs help to support the latest technologies such as Service Oriented Architectures (SOAs), which provide components and even legacy systems to the network in the form of services. These services should be structured so that they can cooperate and interact without requiring highly specialized human skills and/or specially designed and constructed software. ESBs assist with these interactions, effectively acting as an “enterprise nervous system” (Craggs white paper, quoting the Gartner Group, p. 5) by providing an “IT backbone” (Craggs white paper, p. 6). ESBs are prepackaged and are preferably usable “off the shelf”; however, as described in greater detail below, not all ESBs meet this goal.
According to the above white paper, in order to perform these tasks effectively and return the maximum value to the organization (enterprise), ESBs should have the following features: messaging, transformation, and intelligent routing services, particularly by using XML (extensible mark-up language; described in greater detail below); support for Web services and other types of services, including having a SOA structure; support for distributed components; and such features as manageability, scalability, robustness to failure and so forth (p. 9 of the above white paper).
Messaging may be transmitted through a message architecture concept called MOM (messaging oriented middleware), which is used to support message distribution without a strict orientation to the destination of the message, or connection required to send that message. For example, MOM architectures support content-based routing for messages, in which a message is distributed by topic rather than by an address. It should be noted that such routing currently does not involve actual analysis of the content of the message itself. MOM architectures also support asynchronous message delivery, and the ability of applications (components) in a network to subscribe to messages and to publish messages. All of these facilities should be extended by the ESB architecture, through the use of message brokers. Unfortunately, such message brokers are centralized, and may cause single point of failure and/or bottleneck problems.
MOM is currently being superseded by next generation messaging, which also uses message brokers, but which provides additional functionality to further avoid connection-specific addressing for messages. Unfortunately, this type of technology does not solve the problem of message brokers.
These different architectures typically use (or alternatively may use) XML for messages. XML is a highly standardized language which is easy to parse, transform, analyze and otherwise manipulate. It has a number of disadvantages, however, particularly with regard to the size of the XML messages. Because these messages are comprehensible by humans, and are not binary (machine readable) messages, they tend to be very large. Such large messages in turn place additional stress on currently message system architectures, which rely on one or more centralized brokers. Furthermore, previously designed tools, such as firewalls, cannot always understand or properly handle XML; for example, some known firewalls fail to properly parse and/or block XML messages, even those which are machine to machine communication, because XML messages are different from regular messages.
New tools are therefore required which can handle XML well and which also provide ESB functionality, while avoiding current ESB problems, such as potential single point of failure problems and bottleneck problems caused by the requirement for centralized broker(s). Even the use of more than one such broker simply distributes the problem across more than one point, but does not solve the underlying weakness of a centralized system.